home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-05-19 | 56.8 KB | 1,572 lines |
-
-
-
-
-
-
- Network Working Group P. Kuehn
- Request for Comments: 1329 May 1992
-
-
- Thoughts on Address Resolution for Dual MAC FDDI Networks
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard. Distribution of this memo is
- unlimited.
-
- 1. Abstract
-
- In this document an idea is submitted how IP and ARP can be used on
- inhomogeneous FDDI networks (FDDI networks with single MAC and dual
- MAC stations) by introducing a new protocol layer in the protocol
- suite of the dual MAC stations. Thus two dual MAC stations are able
- to do a load splitting across the two rings and use the double
- bandwidth of 200 Mbits/s as single MAC stations. The new layer is an
- extension of layer 3. For the user, the higher layer protocols, IP
- and ARP the property "dual MAC" is transparent. No modification is
- required in the protocol suite of single MAC stations and transparent
- bridges.
-
- 2. Acknowledgements
-
- This paper is a result of a diploma thesis prepared at the Technical
- University of Munich, Lehrstuhl fuer Kommunikationsnetze, in co-
- operation with the Siemens Nixdorf AG. The author would like to
- thank Jrg Eberspher and Bernhard Edmaier from the university, Andreas
- Thimmel and Jens Horstmeier from the SNI AG at Augsburg for the
- helpful comments and discussions.
-
- 3. Conventions
-
- Primary MAC, P-MAC MAC, placed on the primary ring
- Secondary MAC, S-MAC MAC, placed on the secondary ring
- Inhomogeneous ring configuration of a dual FDDI ring with
- single MAC and dual MAC stations
-
- DMARP Dual MAC Address Resolution Protocol
-
- 4. Assumptions
-
- When a dual FDDI ring wraps, both MACs in a dual MAC station are
- assumed to remain connected to the ring. ANSI is just investigating
- whether the Configuration Management in the Station Management of a
-
-
-
- Kuehn [Page 1]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- FDDI station can be modified to allow this. According to the FDDI
- SMT standard [1], different addresses are required for all MACs on
- the primary and the secondary ring.
-
- In this paper, the MAC in a single MAC station is assumed to reside
- on the primary ring. The application of single MAC stations which
- have their MAC attached to the secondary ring is not precluded, but
- therefor additional connectivity between the two rings is required.
- These configurations are beyond the scope of this document.
-
- 5. The Application of Transparent Bridges
-
- Transparent bridges can provide links to other 802 LANs or further
- inhomogeneous FDDI rings. The connection between two inhomogeneous
- FDDI rings can be realized by one or two transparent bridges. When
- two transparent bridges are used, one transparent bridge links the
- primary rings, the other the secondary rings. If two secondary rings
- are connected by a transparent bridge, a path of transparent bridges
- must exist between the two primary rings. No transparent bridges are
- allowed between the primary and the secondary ring.
-
- 6. Protocol Layers in Single MAC Stations
-
- The new protocol layer, named load sharing layer, is drafted to be
- introduced only in dual MAC stations. In single MAC stations, IP and
- ARP are working on top of the Subnetwork Access Protocol (SNAP) 04]
- and the Logical Link Control protocol (802.2 LLC) [3]. LLC type 1 is
- used because connectionless services are investigated only.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kuehn [Page 2]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- +--------------------------+
- | IP |
- +--------------------------+
- +--------------------------+
- | ARP |
- +--------------------------+
- | |
- | ARP frames | IP frames
- | |
- +--------------------------+
- | SNAP |
- +--------------------------+
- +--------------------------+
- | LLC |
- +--------------------------+
- +--------------------------++-------+
- | FDDI-MAC || F |
- +--------------------------+| D S |
- +--------------------------+| D M |
- | FDDI PHY and PMD || I T |
- +--------------------------++-------+
-
- For the ARP layer, the following model is assumed:
- +-------------------------------------------------------X-----------+
- | - ARP entity - | |
- | | IP frames |
- | +----------------+ +----------------+ read | |
- | | Cache | | | entries +-------------+ |
- | | Administration |->-| Address Cache |------>--| Address | |
- | +----------------+ | | | Conversion | |
- | | +----------------+ | Unit | |
- | | ARP frames +-------------+ |
- | | / | |
- | | ___________ <- ARP requests _________________/ | IP frames |
- | |/ | |
- +-----X-------------------------------------------------X-----------+
-
- The Address Conversion Unit handles the actual conversion of IP
- addresses to hardware addresses. For this purpose, it uses the
- information in the ARP cache. The cache administration communicates
- with other ARP entities by ARP and creates, deletes and renews the
- entries in the cache.
-
- 7. Protocol Layers in Dual MAC Stations
-
- The load sharing layer provides the same interface to ARP as SNAP
- does. To exchange information about addresses and reachability, the
- load sharing entities in dual MAC stations communicate with the Dual
-
-
-
- Kuehn [Page 3]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- MAC Address Resolution Protocol (DMARP). For the transmission of
- DMARP frames the SNAP SAP of LLC is used, as for IP and ARP, too.
- The Organizationally Unique Identifier (OUI) in the SNAP header is
- set to zero (24 bit), the EtherType field (16 bit) contains a new
- number indicating DMARP, which is not defined yet.
-
- +---------------------------------------------------------+
- | IP |
- +---------------------------------------------------------+
- +---------------------------------------------------------+
- | ARP |
- +---------------------------------------------------------+
- | ARP frames | IP frames
- +---------------------------------------------------------+
- | Load Sharing Layer |
- +---------------------------------------------------------+
- | | | | | |
- | ARP | DMARP | IP | ARP | DMARP | IP
- | frames | frames | frames | frames | frames | frames
- | | | | | |
- +-------------------------+ +----------------------------+
- | SNAP 1 | | SNAP 2 |
- +-------------------------+ +----------------------------+
- +-------------------------+ +----------------------------+
- | LLC 1 | | LLC 2 |
- +-------------------------+ +----------------------------+
- +-------------------------+ +----------------------------++-------+
- | Primary MAC | | Secondary MAC || F |
- +-------------------------+ +----------------------------+| D S |
- +---------------------------------------------------------+| D M |
- | FDDI PHY and PMD || I T |
- +---------------------------------------------------------++-------+
-
- 8. Running Inhomogeneous FDDI Rings
-
- 8.1. Exchange of Primary MAC Addresses between Stations
-
- IP and higher layer protocols only use the network independent IP
- addresses. The ARP entity takes upon the conversion of an IP address
- to the appropriate hardware address. To make the property dual MAC"
- transparent, ARP may only know the addresses of MACs on the primary
- ring. Therefore, the load sharing entity always delivers ARP frames
- to SNAP 1 for transmission. By this way, communication with ARP is
- done over the primary ring in normal state. A secondary MAC can
- receive an ARP frame when the dual ring is wrapped and the
- destination hardware address is a multicast or broadcast address.
- These frames will be discarded because they were received twice.
-
-
-
-
- Kuehn [Page 4]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- By this way, the associations of IP addresses to primary MAC
- addresses for the single MAC and dual MAC stations are stored in the
- ARP cache. The ARP cache contains no secondary MAC addresses.
-
- 8.2. Exchange of Secondary MAC Addresses between Dual MAC Stations
-
- The load sharing layer needs to know the secondary MAC addresses of
- the other dual MAC stations. The DMARP is used to get these
- addresses. Whenever the load sharing entity delivers an ARP frame to
- SNAP 1, a DMARP reply frame will be sent on the secondary ring,
- containing the stations primary and secondary MAC address. The
- destination hardware address in this DMARP frame is the broadcast MAC
- address, the EtherType field in the SNAP header identifies DMARP.
- The IP destination address is copied from the ARP frame. If the ARP
- frame that was transmitted parallel to the DMARP reply was a request,
- an ARP reply frame will be sent back to the sending station by the
- ARP entity in the receiving station. When the load sharing layer in
- the receiving station delivers this ARP reply frame to SNAP 1, it
- sends a DMARP reply frame on the secondary ring.
-
- By this way, DMARP exchanges the additionally required secondary MAC
- addresses between the dual MAC stations. This is done parallel to
- the exchange of the ARP frames.
-
- 8.3. Communication of Dual MAC Stations on Different Dual FDDI Rings
-
- If two inhomogeneous dual FDDI rings are connected by one transparent
- bridge, dual MAC stations placed on different dual FDDI rings cannot
- perform a load sharing. If both dual FDDI rings remain in normal
- state, no DMARP reply frames get from one secondary ring to the other
- secondary ring. A dual MAC station realizes another dual MAC station
- placed on the other dual ring as a single MAC station, because it
- only receives ARP frames from it. If one of the dual rings is
- wrapped, a DMARP reply frame can get on the primary ring of the other
- dual ring. A target station on the unwrapped ring receives this
- DMARP frame by the primary MAC and the load sharing entity stores the
- contained addresses in an entry in the address cache. This entry is
- marked with a control bit, named the OR-bit Other ring bit"). No
- load sharing will be done with a station related to an entry with the
- OR-bit set.
-
- If both dual FDDI rings are wrapped, the MACs of all stations reside
- on one ring. Now, dual MAC stations placed on different dual rings
- can communicate with DMARP. If a DMARP reply frame is received by
- the primary MAC and no entry exists for the sending station, a new
- entry with OR-Bit set will be created. Otherwise, the OR-bit will be
- set in the existing entry. If a DMARP reply frame is received by the
- secondary MAC and an entry with OR-bit set already exists for the
-
-
-
- Kuehn [Page 5]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- sending station, the bit will not be reset.
-
- This mechanism provides that no load sharing will be done between
- Dual MAC stations on different dual rings if the dual rings are
- linked with one transparent bridge. An additional DMARP error frame
- is used to provide against errors when a DMARP reply frame gets lost
- on the ring.
-
- 8.4. Timeout of Entries Marked with OR-Bit Set
-
- If a FDDI ring is wrapped, the DMARP reply frames are received by the
- primary and secondary MACs of the target dual MAC stations. In that
- case, the entries for dual MAC stations on the same dual ring are
- also marked with the OR-bit, although the load sharing is possible
- between these stations.
-
- When an OR-bit in an entry is set for the first time, a timer entity
- is started. If the timer entity runs out, a DMARP request frame is
- sent over SNAP 2 to the secondary MAC of the associated target)
- station. Then the entry will be discarded.
-
- If the request cannot be received by the target station because the
- network configuration has changed, there is no entry in the address
- cache for this station any more and no load sharing is computed. If
- the target station receives the DMARP request frame, it sends back a
- DMARP reply frame.
-
- 8.5. Problems with the Application of Large FDDI Networks
-
- With an increasing number of dual FDDI rings, each one linked
- together by two transparent bridges, the probability increases, that
- one of these inhomogeneous dual FDDI rings is wrapped in the moment
- when two dual MAC stations exchange ARP frames and DMARP replies.
-
- If two dual MAC stations are communicating for the first time, the
- probability decreases that a load sharing is really computed after
- the exchange of DMARP replies, although this would be possible
- according to the network configuration. It relies upon the fact,
- that DMARP replies get to the primary ring over the wrapped dual ring
- and only entries marked with the OR-bit set are created. To solve
- this problem further expedients are invented:
-
- At first, entries in the address cache can be marked read-only by the
- setting of the R-bit. In dual MAC stations, entries can be written
- manually for other dual MAC stations that are frequently talked to or
- that have a special importance. The control bits of these entries
- cannot be changed by DMARP.
-
-
-
-
- Kuehn [Page 6]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- Next, additional control bits are introduced. One of these bits is
- the Hold-bit (H-bit). When two dual MAC stations exchange ARP frames
- and DMARP replies to create entries in their address caches, one
- station starts sending a DMARP reply, first. According to the
- network state, it sends an additional DMARP error frame, a moment
- later. Within a maximum period of time (see "Configuring the Timer
- Parameters"), all frames arrive at the neighbour station and are
- received by the primary and/or secondary MAC. If the OR-bit was not
- set for an entry within this period of time, it is clear, that no
- further DMARP frames will be received, which result in setting the
- OR-bit. For such an entry the H-bit is set. As the reception of
- reply and error frames is not sufficient for setting the OR-bit when
- the H-bit is set, the load sharing is assumed to be sure. The
- correctness of the H-bit will be verified in relatively long time
- periods by queries (query and hold frames) at the station associated.
-
- For two communicating stations there exists a possibility to get
- information from a third station. Always, when the OR-bit is set for
- an entry in a dual MAC station, a search frame is transmitted by the
- secondary MAC, containing the own primary MAC address and the primary
- MAC address of the counter station. If a third station can compute a
- sure load sharing with both stations (the H-bit is set for the
- associated entries), the stations can perform a load sharing between
- them, too. The third station informs these stations by sending found
- frames to them.
-
- 8.6. Multicast and Broadcast Addresses in IP Frames
-
- If the destination hardware address of an IP frame is a multicast or
- broadcast hardware address, the frame is always delivered to SNAP 1
- and sent on the primary ring, because one of the addressed stations
- could be a single MAC station. IP frames which are delivered to the
- load sharing entity by SNAP 2 are discarded by the load sharing
- entity. Thus, the duplication of these frames can be prevented.
-
- 9. Internal Structure
-
- One load Sharing entity exists in the load sharing layer. This load
- sharing entity consists of the address cache, the cache
- administration and the multiplexer.
-
-
-
-
-
-
-
-
-
-
-
- Kuehn [Page 7]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- to ARP to ARP
- +----X----------------------------------------------------X--------+
- | | | IP |
- | | ARP frames read | frames |
- | | entries | |
- | +----------------------------+ +---------+ +----------+ |
- | | Cache Administration |->-| Address |---->--| Multi- | |
- | +----------------------------|->-| Cache | | plexer | |
- | | | | | +---------+ | | |
- | | | | | +----------+ |
- | | ARP | DMARP | ARP | DMARP | | |
- | | frames | frames | frames | frames IP | IP | |
- | | | | | frames | frames | |
- | | | | | | | |
- +--X--------X--------X--------X-----------------------X--------X---+
- to SNAP 1 to SNAP 2 to SNAP 1 to SNAP 2
-
- 9.1. The Address Cache
-
- In the address cache, the associations of primary MAC addresses to
- secondary MAC addresses are stored for other dual MAC stations on the
- network. There are no entries for single MAC stations.
-
- Because the OR- and the LS-bit (see table) always have inverted
- values, one of the bits is redundant. Afterwards the examination of
- an entry state gets easier by the introduction of both bits, they are
- defined together. The ARP is able to support other protocol address
- formats than the IP format. To support this ARP property by DMARP,
- the protocol type number as used in the ARP frames is stored in every
- entry of the address cache. So, a dual MAC station is able to
- communicate with another station with DMARP, even if the other
- station does not use IP. The numbers used in DMARP frames and the
- address cache for the protocol type and the address length are taken
- over from ARP.
-
- name length comment
- --------------------------------------------------------------------
-
- P-MAC address 48 bit Address of the primary MAC
- in an other dual MAC station
-
- S-MAC address 48 bit Address of the secondary MAC
- in that station
-
- LS-bit 1 bit A load sharing can be performed
- with that station
- ("Load sharing bit")
-
-
-
-
- Kuehn [Page 8]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- OR-bit 1 bit No load sharing may be done
- with that station
- ("Other ring bit")
-
- H-bit 1 bit The load sharing with that
- station is trusty.
- ("Hold bit")
-
- Q-bit 1 bit A query frame was sent to that
- station, no hold frame was
- received yet ("Query bit")
-
- R-bit 1 bit This entry cannot be changed by
- DMARP ("Read-only bit")
-
- V-bit 1 bit The entry is valid
- ("Valid bit")
-
- subscript 32 bit Unique number, identifying this
- entry
-
- protocol type 16 bit Number of the protocol type
- that was last used in that
- station
-
- 9.2. The Multiplexer
-
- The multiplexer deals with multiplexing the IP frames upon the two
- FDDI rings. Broadcast and multicast frames are always sent on the
- primary ring. Otherwise, the contents of the address cache and a load
- sharing criteria are used to decide on which of the rings an IP frame
- has to be transmitted. If there is no entry for the primary MAC
- address of the destination station in the cache, the IP frame is
- transmitted on the primary ring. If there is an entry for the
- destination station and the LS-bit is set, a load sharing can be done
- with this station. Later on a load sharing criteria, which is beyond
- the scope of this document, decides, which one of the rings is used
- for transmission. An example for a load sharing criteria is the
- length of the transmit queues in the MACs. The multiplexer requires an
- abstract function only, which returns the appropriate ring for the
- transmission of an actual IP frame.
-
- Additionally, the multiplexer filters the received IP frames:
- multicast or broadcast frames received from the secondary MAC are
- discarded.
-
-
-
-
-
-
- Kuehn [Page 9]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- 9.3. The Cache Administration
-
- The cache administration creates and deletes the entries in the
- address cache. For this purpose, it communicates with other load
- sharing entities in other dual MAC stations with the DMARP. The
- cache administration handles the delivery of ARP frames to the ARP
- and the SNAP entity in the station, respectively.
-
- The cache administration needs three timers for the communication with
- the DMARP, which have to be supported by the system environment. Each
- of these timers must support a timer entity for each entry in the
- address cache, whereby a single one is running at a time.
-
- Supported timer services:
-
- TIMER_request(time, name, subscript)
- TIMER_response(name, subscript)
- TIMER_cancel(name, subscript):
-
- A timer entity is started by the service TIMER_request and cancelled
- by the TIMER_cancel service request. The TIMER_response service
- indicates that a timer entity has run out. The parameter name is the
- name of a timer: OR-Entry-Timer, Hold-Timer, or Query-Timer. Each
- entry in the address cache is uniquely identified by a number
- subscript). This number is also the number of an associated timer
- entity. How to dispose these numbers is a question of
- implementation. The parameter time determines the time period when
- the timer runs out. This parameter has the value OR-set-timeout for
- the OR-Entry-Timer, Hold-time for the Hold-Timer and Query-time for
- the Query-Timer.
-
- 9.4. Configuring the Timer Parameters
-
- The OR-set-timeout parameter for the OR-Entry-Timer
-
- The period of time, determined by this parameter, should be
- essentially longer than the maximum time for a frame to travel
- around the entire network. The expression entire network means
- the network which is constituted by the subnetworks linked
- together with transparent bridges. When entries with OR-bit set
- are created continuously for a dual MAC station by the timeout
- mechanism, this parameter determines the periods of time between
- the consecutive requests that are sent to this station. If the
- state of the dual FDDI ring changes and an entry with LS-bit set
- could be created, this parameter additionally determines the
- maximum time until the new entry is created. (If an entry could
- not be created by transmission of search frames.) Therefore, the
- OR-set-timeout parameter should be set to some 10 seconds.
-
-
-
- Kuehn [Page 10]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- The Hold-time parameter for the Hold-Timer
-
- The period of time, determined by this parameter, should as well
- be essentially longer than the maximum time for a frame to travel
- around the entire network. When two stations communicate for the
- first time, they exchange ARP frames and DMARP replies. The
- Hold-time parameter determines the period of time until the load
- sharing is assumed to be accomplished after the setting of the
- LS-bit. In this period of time, the frames mentioned above must
- have reached its destination. If an entry would be marked with
- the H-bit incorrectly, the time until it gets corrected will be
- relatively long (Query time). Proposed dimension: several
- minutes.
-
- The Query-time parameter for the Query-Timer
-
- When an entry is marked with LS- and H-bit it is assumed, that
- load sharing can be performed with the associated station. To
- allow the correction of a wrong value of the H-bit, the
- correctness of the H-bit is tested in periods of time, determined
- by the parameter Query-time. It is tested whether a frame is
- received, which was sent by the secondary MAC to the secondary MAC
- address of the target station. (The target station acknowledges
- the reception of the query frame by a hold frame.) To limit the
- traffic caused by the query and hold frames, the parameter Query-
- time should be set to several minutes.
-
- 9.5. Format of DMARP Frames
-
- fieldname length comment
- --------------------------------------------------------------------
-
- hardware type 16 bit 1 = "ethernet"
-
- protocol type 16 bit 2048D = "Internet
- Protocol"
-
- length of hardware 8 bit Value in octets,
- addresses 6 for 48 bit MAC addresses
-
- length of protocol 8 bit Value in octets,
- addresses 4 for Internet addresses
-
- operation 16 bit 1: "reply"
- 2: "request"
- 3: "error"
- 4: "search"
- 5: "found"
-
-
-
- Kuehn [Page 11]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- 6: "query"
- 7: "hold"
-
- 1. hardware address ... octets
-
- 2. hardware address ... octets
-
- protocol address ... octets
- sender
-
- protocol address ... octets
- receiver
-
- --------------------------------------------------------------------
-
- The value for the field "protocol type" is the same as in ARP frames.
-
- 9.6. Contents of DMARP Frames
-
- In the following tables of DMARP frames, the fields containing the
- length and type of protocol and hardware addresses are omitted.
-
- Format:
-
- +-------------------------------------------------------------+
- | Operation | 1. hardware | 2. hardware | protocol | protocol |
- | | address | address | address | address |
- | | | | sender | receiver |
- +-------------------------------------------------------------+
-
- Operation = 1 (reply), 2 (request), 3 (error):
- +-----------------------------------------------------------------+
- | Operation | P-MAC address | S-MAC address | protocol | protocol |
- | | sender | sender | address | address |
- | | | | sender | receiver |
- +-----------------------------------------------------------------+
-
- +-------------------------------------------------------------------+
- | Operation=4 | P-MAC | P-MAC address | protocol | broadcast |
- | (search) | address | counter- | address | protocol |
- | | sender | station | sender | address |
- +-------------------------------------------------------------------+
-
- +-------------------------------------------------------------------+
- | Operation=5 | P-MAC | S-MAC address | protocol | broadcast |
- | (found) | address | counter- | address | protocol |
- | | sender | station | sender | address |
- +-------------------------------------------------------------------+
-
-
-
- Kuehn [Page 12]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- +-------------------------------------------------------------------+
- | Operation=6 | S-MAC | P-MAC address | protocol | broadcast |
- | (query) | address | counter- | address | protocol |
- | | sender | station | sender | address |
- +-------------------------------------------------------------------+
-
- +-------------------------------------------------------------------+
- | Operation=7 | P-MAC address | S-MAC address | protocol | protocol |
- | (hold) | sender | sender | address | address |
- | | | | sender | receiver |
- +-------------------------------------------------------------------+
-
- Apart from the error frames all frames are sent on the secondary
- ring. The reply, error and search frames are addressed to the
- broadcast hardware address. The request, found, query and hold
- frames are addressed to an individual secondary MAC address.
-
- 10. Formal Description
-
- The following description is written in ESTELLE.
-
- 10.1. Global Constants, Variables and Types
-
- default individual queue;
-
- timescale ...;
-
- type
-
- PDU_type = ... ; (* format of a Protocol Data Unit:
- String of variable length *)
- HW_addr_type = ... ; (* format of a 48 bit MAC address *)
- PR_addr_type = ... ; (* General: format of a protocol address
- in an ARP or DMARP frame *)
- IP_addr_type = ... ; (* General: format of an IP address *)
- QoS_type = ... ; (* General: format of a Quality-of-
- -Service statement *)
- timer_name_type = ... ; (* Type for the name of a system timer *)
-
- flag = (reset,set);
-
- var
-
- (*
- The values of these variables are set in the initialization part or
- by external management functions.
- *)
-
-
-
-
- Kuehn [Page 13]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- My_P_MAC_addr : HW_addr_type; (* Address of the MAC, placed on
- the primary ring *)
- My_S_MAC_addr : HW_addr_type; (* Address of the MAC, placed on
- the secondary ring *)
- My_IP_address : IP_addr_type; (* IP address of this station *)
- Broadcast_HW_addr : HW_addr_type; (* Broadcast MAC address (48 bit) *)
- Broadcast_IP_addr : IP_addr_type; (* Broadcast IP address *)
- dmarp_QoS : QoS_type; (* Quality_of_Service-statement
- for DMARP frames *)
-
- ethernet : integer; (* Type statement in DMARP frames *)
- ip : integer; (* Number for IP as protocol type *)
- fddi_addr_length : integer; (* Length of a MAC address in octetts *)
- ip_addr_length : integer; (* Length of a IP address in octetts *)
-
- OR_set_timeout : integer; (* Parameter for the OR-Entry-Timer *)
- Query_time : integer; (* Parameter for the Hold-Timer *)
- Hold_time : integer; (* Parameter for the Query-Timer *)
-
- 10.2. Channels
-
- channel SAPchn(User,Provider);
- by User :
- UNITDATA_request
- (
- Source_addr : HW_addr_type;
- Dest_addr : HW_addr_type;
- QoS : QoS_type;
- PDU : PDU_type;
- )
- by Provider :
- UNITDATA_indication
- (
- Source_addr : HW_addr_type;
- Dest_addr : HW_addr_type;
- QoS : QoS_type;
- PDU : PDU_type;
- )
-
- channel System_Access_Point_chn(User,Provider);
- by User:
- TIMER_request(Time : integer;
- Timer_id : timer_name_type;
- subscript : integer);
-
- TIMER_cancel(Timer_id : timer_name_type;
- subscript : integer);
-
-
-
-
- Kuehn [Page 14]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- by Provider:
- TIMER_response(Timer_id : timer_name_type;
- subscript : integer);
-
-
- 10.3. The Module Header and Interaction Points
-
- module LS_module systemprocess;
- ip LS_ARPSAP : SAPchn(Provider);
- LS_IPSAP : SAPchn(Provider);
- SNAP1_ARPSAP : SAPchn(User);
- SNAP1_LSSAP : SAPchn(User);
- SNAP1_IPSAP : SAPchn(User);
- SNAP2_ARPSAP : SAPchn(User);
- SNAP2_LSSAP : SAPchn(User);
- SNAP2_IPSAP : SAPchn(User);
- LS_System_Access_Point : System_Access_Point_chn(User);
- end;
-
- 10.4. The Modulebody of the Load Sharing Entity
-
- body LS_body for LS_module;
-
- module multiplexer_module process;
- ip LS_IPSAP : SAPchn(Provider);
- SNAP1_IPSAP : SAPchn(User);
- SNAP2_IPSAP : SAPchn(User);
- end;
-
- module cache_administration_module process;
- ip LS_ARPSAP : SAPchn(Provider);
- SNAP1_ARPSAP : SAPchn(User);
- SNAP1_LSSAP : SAPchn(User);
- SNAP2_ARPSAP : SAPchn(User);
- SNAP2_LSSAP : SAPchn(User);
- LS_System_Access_Point : System_Access_Point_chn(User);
- end;
-
- body cache_administration_body for cache_administration_module;
- (* defined later *)
- end;
-
- body multiplexer_body for multiplexer_module;
- (* defined later *)
- end;
-
- modvar
- cache_administration : cache_administration_module;
-
-
-
- Kuehn [Page 15]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- multiplexer : multiplexer_module;
-
- initialize
- begin
- ethernet := 1;
- ip := 2048;
- fddi_addr_length := 6;
- ip_addr_length := 4;
- init cache_administration with cache_administration_body;
- init multiplexer with multiplexer_body;
- attach LS_IPSAP to multiplexer.LS_IPSAP;
- attach SNAP1_IPSAP to multiplexer.SNAP1_IPSAP;
- attach SNAP2_IPSAP to multiplexer.SNAP2_IPSAP;
- attach LS_ARPSAP to cache_administration.LS_ARPSAP;
- attach SNAP1_ARPSAP to cache_administration.SNAP1_ARPSAP;
- attach SNAP1_LSSAP to cache_administration.SNAP1_LSSAP;
- attach SNAP2_ARPSAP to cache_administration.SNAP2_ARPSAP;
- attach SNAP2_LSSAP to cache_administration.SNAP2_LSSAP;
- attach LS_System_Access_Point to cache_administration.
- LS_System_Access_Point;
- end; end;
-
- 10.5. The Modulebody for the Multiplexer
-
- body multiplexer_body for multiplexer_module;
-
- type
- Type_of_addr_type = (individual, multi, broad);
- ring_type = (primary, secondary);
-
- var
- act_S_MAC_addr : HW_addr_type;
-
- function determ_addrtype(HW_addr: HW_addr_type): Type_of_addr_type;
- primitive;
- (*
- Returns the type of a hardware address.
- (Individual, multicast or broadcast address)
- *)
-
- function get_cacheentry(prtype: integer; P_MAC_addr: HW_addr_type;
- var S_MAC_addr : HW_addr_type): boolean;
- primitive;
- (*
- Returns the associated secondary MAC address for a given primary MAC
- address and protocol type. If an entry exists, the value TRUE is
- returned.
- *)
-
-
-
- Kuehn [Page 16]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- function ls_criteria : ring_type;
- (*
- Returns the ring on which the actual frame should be transmitted.
- *)
- primitive;
-
- trans
-
- when LS_IPSAP.UNITDATA_request(Source_addr,Dest_addr,QoS,PDU) begin
- if determ_addrtype(Dest_addr) <> individual then
- output SNAP1_IPSAP.UNITDATA_request(Source_addr,Dest_addr,QoS,PDU);
- else begin
- if get_cacheentry(ip,Dest_addr,act_S_MAC_addr) and
- (ls_criteria=secondary) then
- output SNAP2_IPSAP.UNITDATA_request(My_S_MAC_addr,
- act_S_MAC_addr,QoS,PDU);
- else
- output SNAP1_IPSAP.UNITDATA_request(Source_addr,Dest_addr,QoS,PDU);
- end;
- end;
-
- when SNAP1_IPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU)
- begin
- output LS_IPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU);
- end;
-
- when SNAP2_IPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU)
- begin
- if determ_addrtype(Dest_addr) = individual then begin
- Dest_addr := My_P_MAC_addr;
- output LS_IPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU);
- end;
- end;
-
- 10.6. The Modulebody for the Cache Administration
-
- body cache_administration_body for cache_administration_module;
-
- type
- arp_pdu_type = record
- hwtype : integer;
- prtype : integer;
- HW_length : integer;
- PR_length : integer;
- operation : (request,reply);
- HW_sender : HW_addr_type;
- PR_sender : PR_addr_type;
- HW_receiver : HW_addr_type;
-
-
-
- Kuehn [Page 17]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- PR_receiver : PR_addr_type;
- end;
-
- dmarp_operation_type = (request,reply,error,search,found,query,hold);
-
- dmarp_pdu_type = record
- hwtype : integer;
- prtype : integer;
- HW_length : integer;
- PR_length : integer;
- operation : dmarpoperation_type;
- HW_1 : HW_addr_type;
- HW_2 : HW_addr_type;
- PR_sender : PR_addr_type;
- PR_receiver : PR_addr_type;
- end;
-
- var
- arp_pdu : arp_pdu_type;
- dmarp_pdu : dmarp_pdu_type;
- send_pdu : dmarp_pdu_type;
- act_P_MAC_addr : HW_addr_type;
-
- function my_pr_address(prtype : integer ; praddr : PR_addr_type):
- boolean;
- (*
- Returns TRUE, if praddr is my station address, the protocol type is
- prtype. (2048d for the Internet protocol)
- *)
- primitive;
-
- function get_my_pr_addr(prtype : integer) : PR_addr_type;
- (*
- Returns my station address, the protocol has the number prtype.
- *)
-
- function extract_arp_pdu(PDU : PDU_type) : arp_pdu_type;
- (*
- Returns the data contained in an ARP PDU as a record.
- *)
- primitive;
-
- function extract_dmarp_pdu(PDU : PDU_type) : dmarp_pdu_type;
- (*
- Returns the data contained in an DMARP PDU as a record.
- *)
- primitive;
-
-
-
-
- Kuehn [Page 18]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- function assemble_dmarp_pdu(dmarp_pdu : dmarp_pdu_type): PDU;
- (*
- Returns a DMARP PDU from the data in the record.
- *)
- primitive;
-
- procedure create_entry(prtype: integer; P_MAC_addr: HW_addr_type;
- S_MAC_addr: HW_addr_type; LS_Bit: flag; OR_Bit: flag;
- H_Bit: flag; Q_Bit: flag; R_Bit: flag; V_Bit: flag);
- (*
- Creates a new entry in the address cache, if no entry with the given
- primary MAC address or R-bit set to one exists. The protocol type has
- the number prtype. The control bits are set as given in the parameters,
- the LS-bit is set last.
- *)
- primitive;
-
- function search_entry(prtype : integer; P_MAC_addr : HW_addr_type):
- boolean;
- (*
- Returns TRUE if an entry with the primary MAC address P_MAC_addr and
- the given protocol type was found in the address cache.
- *)
- primitive;
-
- procedure update_entry(prtype: integer; P_MAC_addr: HW_addr_type;
- S_MAC_addr: HW_addr_type);
- (*
- Searches an entry with the given primary MAC address P_MAC_address and
- updates the secondary MAC address in the entry if the R-bit is set to
- zero.
- *)
- primitive;
-
- procedure reset_LS_bit(prtype: integer; P_MAC_addr : HW_addr_type);
- (*
- Searches an entry with the given primary MAC address P_MAC_address and
- resets the LS-bit if the R-bit is reset.
- *)
- primitive;
-
- procedure set_Q_bit(prtype: integer; P_MAC_addr : HW_addr_type);
- (*
- Searches an entry with the given primary MAC address P_MAC_address and
- sets the Q-bit if the R-bit is reset.
- *)
- primitive;
-
-
-
-
- Kuehn [Page 19]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- function H_bit_set(prtype: integer; P_MAC_addr : HW_addr_type):
- boolean;
- (*
- Returns TRUE if an entry exists with H-bit set to one and the given
- P-MAC address.
- *)
- primitive;
-
- function OR_bit_set(prtype: integer; P_MAC_addr : HW_addr_type):
- boolean;
- (*
- Returns TRUE if an entry exists with OR-bit set to one and the given
- P-MAC address.
- *)
- primitive;
-
- function LS_bit_set(prtype: integer; P_MAC_addr : HW_addr_type):
- boolean;
- (*
- Returns TRUE if an entry exists with LS-bit set to one and the given
- P-MAC address.
- *)
- primitive;
-
- function Q_bit_set(prtype: integer; P_MAC_addr : HW_addr_type):
- boolean;
- (*
- Returns TRUE if an entry exists with Q-bit set to one and the given
- P-MAC address.
- *)
- primitive;
-
- function get_subscript(prtype: integer; P_MAC_addr : HW_addr_type):
- integer;
- (*
- Returns the subscipt number of an entry with the given primary MAC
- address.
- *)
- primitive;
-
- function get_broadcast_addr(prtype : integer): PR_addr_type;
- (*
- Returns the broadcast protocol address for the given protocol type.
- *)
-
- function get_P_MAC_addr(subscript : integer) : HW_addr_type;
- (*
- Returns the primary MAC address of the entry with the given subscript
-
-
-
- Kuehn [Page 20]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- number.
- *)
- primitive;
-
- function get_S_MAC_addr(prtype: integer; P_MAC_addr: HW_addr_type):
- HW_addr_type;
- (*
- Returns the secondary MAC address of the station with the given primary
- MAC address.
- *)
- primitive;
-
- procedure delete_entry(subscript : integer);
- (*
- Deletes the entry with the given subscript number if the R-bit is
- reset.
- *)
- primitive;
-
- function get_pr_type(subscript : integer) : integer;
- (*
- Returns the protocol type for the entry with the given subscript
- number.
- *)
- primitive;
-
- function get_pr_length(prtype : integer) : integer;
- (*
- Returns the length of a protocol address.
- *)
- primitive;
-
-
- trans
-
- when LS_ARPSAP.UNITDATA_request(Source_addr,Dest_addr,QoS,PDU)
- begin
- arp_pdu := extract_arp_pdu(PDU);
- output SNAP1_ARPSAP.UNITDATA_request(Source_addr,Dest_addr,QoS,PDU);
- dmarp_pdu.hwtype := ethernet;
- dmarp_pdu.prtype := arp_pdu.prtype;
- dmarp_pdu.HW_length := fddi_addr_length;
- dmarp_pdu.PR_length := arp_pdu.PR_length;
- dmarp_pdu.operation := reply;
- dmarp_pdu.HW_1 := My_P_MAC_addr;
- dmarp_pdu.HW_2 := My_S_MAC_addr;
- dmarp_pdu.PR_sender := arp_pdu.PR_sender;
- dmarp_pdu.PR_receiver := arp_pdu.PR_receiver;
-
-
-
- Kuehn [Page 21]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- PDU := assemble_dmarp_pdu(dmarp_pdu);
- output SNAP2_LSSAP.UNITDATA_request(My_S_MAC_addr,Broadcast_HW_addr,
- dmarp_QoS,PDU);
- end;
-
-
- when SNAP1_ARPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU)
- begin
- output LS_ARPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU);
- end;
-
- when SNAP2_ARPSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU)
- begin end;
-
- when SNAP1_LSSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU)
- begin
- dmarp_pdu := extract_dmarp_pdu(PDU);
- if ((dmarp_pdu.operation = error) or (dmarp_pdu.operation = reply))
- then begin
- if my_pr_address(dmarp_pdu.prtype,dmarp_pdu.PR_receiver) then begin
- if not H_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then begin
- if not OR_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then begin
- if LS_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then begin
- output LS_System_Access_point.TIMER_cancel(
- "Hold_Timer",get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- create_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2,
- reset,set,reset,reset,reset,set);
- end;
- output LS_System_Access_point.TIMER_request(
- OR_set_timeout,"OR_Entry_Timer",
- get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- send_pdu.hwtype := ethernet;
- send_pdu.prtype := dmarp_pdu.prtype;
- send_pdu.HW_length := fddi_addr_length;
- send_pdu.PR_length := dmarp_pdu.PR_length;
- send_pdu.operation := search;
- send_pdu.HW_1 := My_P_MAC_addr;
- send_pdu.HW_2 := dmarp_pdu.HW_1;
- send_pdu.PR_sender := get_my_pr_addr(dmarp_pdu.prtype);
- send_pdu.PR_receiver := get_broadcast_addr(dmarp_pdu.prtype);
- PDU := assemble_dmarp_pdu(dmarp_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,Broadcast_HW_addr,dmarp_QoS,PDU);
- end else begin
- if dmarp_pdu.operation=error then
- update_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2);
- end;
- end else begin
-
-
-
- Kuehn [Page 22]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- if dmarp_pdu.operation = error then
- update_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2);
- end;
- end else begin
- if my_pr_address(dmarp_pdu.prtype,dmarp_pdu.PR_sender) and
- (dmarp_pdu.operation = reply) then begin
- dmarp_pdu.operation := error;
- PDU := assemble_dmarp_pdu(dmarp_pdu);
- output SNAP1_LSSAP.UNITDATA_request(
- My_P_MAC_addr,Broadcast_HW_addr,dmarp_QoS,PDU);
- end else begin
- if dmarp_pdu.operation=error and
- search_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1) then
- update_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2);
- end; end; end; end;
-
-
- when SNAP2_LSSAP.UNITDATA_indication(Source_addr,Dest_addr,QoS,PDU)
- begin
- dmarp_pdu := extract_dmarp_pdu(PDU);
- if (dmarp_pdu.operation = found) and
- my_pr_address(dmarp_pdu.prtype,dmarp_pdu.PR_receiver) then begin
- if not H_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then begin
- if OR_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then begin
- output LS_System_Access_Point.
- TIMER_cancel("OR_Entry_Timer",
- get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- end;
- if LS_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then begin
- output LS_System_Access_Point.
- TIMER_cancel("Hold_Timer",
- get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- end;
- create_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2,
- set,reset,set,reset,reset,set);
- output LS_System_Access_Point.TIMER_request(Query_time,"Query_Timer",
- get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- end;
- end else begin
- if (dmarp_pdu.operation = reply) or
- (dmarp_pdu.operation = request) then begin
- if search_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1) then
- update_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2);
- end;
- if (dmarp_pdu.operation=request) and
- my_pr_address(dmarp_pdu.prtype,dmarp_pdu.PR_receiver) then begin
- send_pdu.hwtype := dmarp_pdu.hwtype;
- send_pdu.prtype := dmarp_pdu.prtype;
-
-
-
- Kuehn [Page 23]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- send_pdu.HW_length := fddi_addr_length;
- send_pdu.PR_length := dmarp_pdu.PR_length;
- send_pdu.operation := reply;
- send_pdu.HW_1 := My_P_MAC_addr;
- send_pdu.HW_2 := My_S_MAC_addr;
- send_pdu.PR_sender := get_my_pr_addr(dmarp_pdu.prtype);
- send_pdu.PR_receiver := dmarp_pdu.PR_sender;
- PDU := assemble_dmarp_pdu(dmarp_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,Broadcast_HW_addr,dmarp_QoS,PDU);
- end else begin
- if my_pr_address(dmarp_pdu.prtype,dmarp_pdu.pr_receiver) then begin
- case dmarp_pdu.operation of
- reply: begin
- if not ( OR_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) or
- LS_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) )then begin
- create_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2,
- set,reset,reset,reset,reset,set);
- output LS_System_Access_Point.TIMER_request(Hold_time,
- "Hold_Timer",get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- end;
- end;
-
- error: begin
- if not ( OR_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) or
- H_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) ) then begin
- if LS_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then
- output LS_System_access_point.TIMER_cancel(
- "Hold_Timer",get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- create_entry(dmarp_pdu.prtype,dmarp_pdu.HW_1,dmarp_pdu.HW_2,
- reset,set,reset,reset,reset,set);
- output LS_System_access_point.TIMER_request(
- OR_set_timeout,"OR_Entry_Timer",
- get_subscript(dmarp_pdu.prtype,dmarp_pdu.HW_1));
- send_pdu.hwtype := ethernet;
- send_pdu.prtype := dmarp_pdu.prtype;
- send_pdu.HW_length := fddi_addr_length;
- send_pdu.PR_length := dmarp_pdu.PR_length;
- send_pdu.operation := search;
- send_pdu.HW_1 := My_P_MAC_addr;
- send_pdu.HW_2 := dmarp_pdu.HW_1;
- send_pdu.PR_sender := get_my_pr_addr(dmarp_pdu.prtype);
- send_pdu.PR_receiver := get_broadcast_addr(dmarp_pdu.prtype);
- PDU := assemble_dmarp_pdu(dmarp_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,Broadcast_HW_addr,dmarp_QoS,PDU);
- end;
- end;
-
-
-
- Kuehn [Page 24]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- search: begin
- if not (dmarp_pdu.HW_1=My_P_MAC_addr or
- dmarp_pdu.HW_2=My_P_MAC_addr) then begin
- if H_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) and
- H_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_2) then begin
- send_pdu.hwtype := ethernet;
- send_pdu.prtype := dmarp_pdu.prtype;
- send_pdu.HW_length := fddi_addr_length;
- send_pdu.PR_length := dmarp_pdu.PR_length;
- send_pdu.operation := found;
- send_pdu.HW_1 := dmarp_pdu.HW_2;
- send_pdu.HW_2 := get_S_MAC_addr(dmarp_pdu.prtype,
- dmarp_pdu.HW_2);
- send_pdu.PR_sender := get_my_pr_addr(dmarp_pdu.prtype);
- send_pdu.PR_receiver := get_broadcast_addr(dmarp_pdu.prtype);
- PDU := assemble_dmarp_pdu(send_pdu);
- output SNAP2_LSSAP.UNITDATA_request(My_S_MAC_addr,
- get_S_MAC_addr(dmarp_pdu.prtype,dmarp_pdu.HW_1),dmarp_QoS,PDU);
- send_pdu.HW_1 := dmarp_pdu.HW_1;
- send_pdu.HW_2 := get_S_MAC_addr(dmarp_pdu.prtype,
- dmarp_pdu.HW_1);
- PDU := assemble_dmarp_pdu(send_pdu);
- output SNAP2_LSSAP.UNITDATA_request(My_S_MAC_addr,
- get_S_MAC_addr(dmarp_pdu.prtype,dmarp_pdu.HW_2),dmarp_QoS,PDU);
- end;
- end;
- end;
-
-
- Query: begin
- if dmarp_pdu.HW_2 = My_P_MAC_addr then begin
- send_pdu.hwtype := ethernet;
- send_pdu.prtype := dmarp_pdu.prtype;
- send_pdu.HW_length := dmarp_pdu.HW_length;
- send_pdu.PR_length := dmarp_pdu.PR_length;
- send_pdu.operation := hold;
- send_pdu.HW_1 := My_P_MAC_addr;
- send_pdu.HW_2 := My_S_MAC_addr;
- send_pdu.PR_sender := get_my_pr_addr(dmarp_pdu.prtype);
- send_pdu.PR_receiver := dmarp_pdu.PR_sender;
- PDU := assemble_dmarp_pdu(send_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,dmarp_pdu.HW_1,dmarp_QoS,PDU);
- end;
- end;
- Hold: begin
- if H_bit_set(dmarp_pdu.prtype,dmarp_pdu.HW_1) then
- reset_Q_bit(dmarp_pdu.prtype,dmarp_pdu.HW_1);
-
-
-
- Kuehn [Page 25]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- end;
- end;
- end;
- end;
- end;
- end;
-
-
- when LS_System_Access_Point.TIMER_response(Timer_name,subscript) begin
- case Timer_name of
- "OR_Entry_Timer": begin
- act_P_MAC_addr := get_P_MAC_addr(subscript);
- if OR_bit_set(get_pr_type(subscript),act_P_MAC_addr) then begin
- send_pdu.hwtype := ethernet;
- send_pdu.prtype := get_pr_type(subscript);
- send_pdu.HW_length := fddi_addr_length;
- send_pdu.PR_length := get_pr_length(send_pdu.prtype);
- send_pdu.operation := request;
- send_pdu.HW_1 := My_P_MAC_addr;
- send_pdu.HW_2 := My_S_MAC_addr;
- send_pdu.PR_sender := get_my_pr_addr(send_pdu.prtype);
- send_pdu.PR_receiver := get_broadcast_addr(send_pdu.prtype);
- PDU := assemble_dmarp_pdu(send_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,get_S_MAC_addr(send_pdu.prtype,act_P_MAC_addr),
- dmarp_QoS,PDU);
- delete_entry(subscript);
- end;
- end;
- "Hold_Timer": begin
- act_P_MAC_addr := get_P_MAC_addr(subscript);
- if (not H_bit_set(get_pr_type(subscript),act_P_MAC_addr)) and
- LS_bit_set(get_pr_type(subscript),act_P_MAC_addr) then begin
- set_H_bit(get_pr_type(subscript),act_P_MAC_addr);
- output LS_System_Access_point.TIMER_request(
- Query_time,"Query_Timer",subscript);
- end;
- end;
- "Query_Timer": begin
- act_P_MAC_addr := get_P_MAC_addr(subscript);
- send_pdu.hwtype := ethernet;
- send_pdu.prtype := get_pr_type(subscript);
- send_pdu.HW_length := fddi_addr_length;
- send_pdu.PR_length := get_pr_length(send_pdu.prtype);
- send_pdu.PR_sender := get_my_pr_addr(send_pdu.prtype);
- send_pdu.PR_receiver := get_broadcast_addr(send_pdu.prtype);
- if Q_bit_set(get_pr_type(subscript),act_P_MAC_addr) then begin
- send_pdu.HW_1 := My_P_MAC_addr;
-
-
-
- Kuehn [Page 26]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- send_pdu.HW_2 := My_S_MAC_addr;
- send_pdu.operation := request;
- PDU := assemble_dmarp_pdu(send_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,get_S_MAC_addr(send_pdu.prtype,act_P_MAC_addr),
- dmarp_QoS,PDU);
- delete_entry(subscript);
- end else begin
- send_pdu.HW_1 := My_S_MAC_addr;
- send_pdu.HW_2 := get_P_MAC_addr(subscript);
- send_pdu.operation := query;
- PDU := assemble_dmarp_pdu(send_pdu);
- output SNAP2_LSSAP.UNITDATA_request(
- My_S_MAC_addr,get_S_MAC_addr(send_pdu.prtype,send_pdu.HW_2),
- dmarp_QoS,PDU);
- set_Q_bit(send_pdu.prtype,send_pdu.HW_2);
- end; end; end; end; end; (* body *)
-
- 11. Summary
-
- The introduction of the load sharing layer in the protocol layering
- of the dual MAC stations allows the application of IP and ARP on
- inhomogeneous FDDI rings. The protocol suite of single MAC stations
- needs no modification.
-
- By the load sharing layer, the property "dual MAC" is transparent for
- ARP, IP and the higher layer protocols.
-
- In dual MAC stations, any load sharing criteria may be implemented in
- the multiplexer of the load sharing entity. The conversion of
- addresses, the exchange of address and reachability information
- between dual MAC stations and the proper transmission of multicast
- and broadcast frames is taken upon by the load sharing entity.
-
- 12. References
-
- [1] ANSI, "FDDI Station Management (SMT)", ANSI
- X3T9/90-X3T9.5/84-49 Rev 6.2, May 1990.
-
- [2] ANSI, "FDDI Media Access Control (MAC-2)",
- X3T9/90-X3T9.5/88-139 Rev 3.2, June 1990.
-
- [3] ISO, "Information processing systems- Local area networks-
- Part 2: Logical link control", ISO 8802-2:1989, August 1989.
-
- [4] IEEE, "Draft Standard P802.1A Overview and Architecture",
- P802.1A/D9-89/74, September 1989.
-
-
-
-
- Kuehn [Page 27]
-
- RFC 1329 Address Resolution for Dual MAC FDDI Networks May 1992
-
-
- [5] Plummer, C., "An Ethernet Address Resolution Protocol --or--
- Converting Network Protocol Addresses to 48.bit Ethernet
- Address for Transmission on Ethernet Hardware", RFC 826, MIT,
- November 1982.
-
- [6] Reynolds, J., and Postel, J., "Assigned Numbers", RFC 1060,
- USC/Information Sciences Institute, March 1990.
-
- [7] Postel, J., "Internet Protocol", RFC 791, USC/Information
- Sciences Institute, September 1981.
-
- [8] Katz, D., "A Proposed Standard for the Transmission of IP
- Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET,
- October 1990.
-
- [9] Internet Engineering Task Force, Braden, R., Editor,
- "Requirements for Internet Hosts -- Communication Layers",
- RFC 1122, IETF, October 1989.
-
- [10] Katz, D., "The Use of Connectionless Network Layer Protocols
- over FDDI Networks", Merit/NSFNET, 1990.
-
- 13. Security Considerations
-
- Security issues are not discussed in this memo.
-
- 14. Author's Address
-
- Peter Kuehn
- Raiffeisenstrasse 9b
- 8933 Untermeitingen
- Germany
-
- Phone: .. 82 32 / 7 46 02
- EMail: thimmela@sniabg.wa.sni.de
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Kuehn [Page 28]
-
-